As mentioned in Jupyter-contrib/jupyter_contrib_core#1, the config-dir kwarg isn't present in notebook 4.2, and as a result doesn't make sense to add to jupyter_contrib_core.notebook_compat (which is intended to be a shim providing 4.2-equivalent API). Rather, the config-dir parameter should be handled directly in the jupyter_contrib_nbextensions apps and functions. I built this into my themysto effort a while back, I think, so I'll see if I can resurrect it from that...

@flying-sheep I've been thinking about this a bit recently. Although I have managed to create working versions which accept a config_dir parameter, they necessitate rewriting lots of the upstream (de)activation code, which all depends on the get_config_dir function, and as a result feel very brittle to changes in the notebook API. As an alternative methodology, I suggest we consider using a user install, in combination with temporarily setting the environment variable JUPYTER_CONFIG_DIR (and potentially also JUPYTER_DATA_DIR) to appropriate values. Since the main usage case is installing by package maintainers, I think we can neglect potential side-effects of temporarily altering os.environ. Any thoughts?

hmm, where do runtime components get the config dir location from?

is it possible that they can’t cope with custom/systemwide installations?

hmm, where do runtime components get the config dir location from?

I guess you mean where does the notebook server (and similar) look for config? Well, it's slightly OS-dependent, but I think in general they look at all directories in jupyter_core.paths.jupyter_config_path. They certainly seems to cope ok with installations to system & sys_prefix directories (also defined in jupyter_core.paths) ok

I should add, the environment variable JUPYTER_CONFIG_DIR is returned by jupyter_core.paths.jupyter_config_dir, which in turn is used as the first entry in the list returned by jupyter_core.path.jupyter_config_path

ah, makes sense. so if i want to use /etc/jupyter setting $JUPYTER_CONFIG_DIR during installation will work, and the kernel/nbconvert/whatever will also find it, right?

the kernel/nbconvert/whatever will also find it, right?

As long as it's also set for their processes, yes, they should find it ok

OK, then i’ll close this. will there be a release with the system-by-default fix in it soon?

i assume the user-by-default will also mess with $JUPYTER_CONFIG_DIR, no?

OK!

it’s a bit awkward, but it works: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=jupyter_contrib_nbextensions

(well, almost. i have to patch a config file which stores the template location wrong)

will there be a release with the system-by-default fix in it soon?

Yes, this was already merged into master in #735 (which also included #725). I'll try to make pypi & conda releases today, assuming I can get twine to play on windows...

Ok, I have pushed 0.2.0 to pypi, conda build to follow once it's also visible on pypi.io (seems to take a while to transfer over).

i assume the user-by-default will also mess with $JUPYTER_CONFIG_DIR, no?

I'm not really sure what you mean here?

great!

what i meant was wrong: actually i (counterintuitively) need to use --user in combination with the $JUPYTER_*_DIR variables to get a true system install.

with that i mean that there’s two kinds of system-wide installations on linux: manually installed stuff goes into /usr/local/{bin,share,lib,etc,...}, while the stuff managed by the package manager goes into /usr/{bin,share,lib} and /etc. and honestly i didn’t know that /usr/local/etc exists.

since jupyter knows about the non-/usr/local install dirs, the functions only return the /usr/local ones, so it takes more fiddling than other kinds of install, but now i have something quite ideal:

/
├── etc/jupyter/
│   ├── jupyter_nbconvert_config.json
│   ├── jupyter_notebook_config.json
│   └── migrated
└── usr/
    ├── bin/jupyter-contrib-nbextension
    ├── lib/python3.5/site-packages/
    │   ├── jupyter_contrib_nbextensions/
    │   │   └── ...
    │   └── jupyter_contrib_nbextensions-0.2.0.dist-info/
    │       └── ...
    └── share/jupyter/nbextensions/
         └── ...

@flying-sheep great, glad you got it working 😄 Thanks for the explanation, too! So are we ok to close this PR then?

yes, but it would be great to have a “true system install” option

sure, though since that's OS-dependent, I think it'd have to be implemented upstream before we could use it reliably 😜